At 9:25 AM -0800 1/24/00, Tom Lane wrote:
>"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
>>> to be useful for cost estimating. We could make it a parameter like
>>> we do for CPU_PAGE_WEIGHT ... but you know and I know that no one
>>> ever bothers to adjust those numbers in the field ...
>
>> Couldn't we test some of these parameters inside configure and set
>> them there?
>
>If we could figure out a reasonably cheap way of estimating these
>numbers, it'd be worth setting up custom values at installation time.
>
>I don't know how to do that --- AFAICS, getting trustworthy numbers by
>measurement would require hundreds of meg of temporary disk space and
>probably hours of runtime. (A smaller test would be completely
>corrupted by kernel disk caching effects.)
Getting a rough estimate of CPU speed is trivial. Getting a rough estimate
of sequential disk access shouldn't be too hard, though you would need to
make sure it didn't give the wrong answer if you ran configure twice in a
row or something. Getting a rough estimate of disk access for a single
non-sequential disk page also shouldn't be too hard with the same caviats.
Measuring sequential vs. random reads probably takes a large dataset as you
say.
I suspect that there is a range of important parameters and we can only
easily measure some of them. If we do so and use canned values (ratios,
where possible) for the others then we're probably still ahead.
I'll leave the details for the people who actually have time to do some of
this stuff.
Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
